#AcceptanceCriteria #jira #PO
不豪小，這是我們一月份開始合作的兩位 PO ，她們所建立的 story, 裡面的 acceptance criteria 是由她們兩位先整理一版出來的。
當然， refinement 時會跟團隊再 tuning 一次，實際如果要轉成自動測試或 BDD 時，也可能要再 tuning 一次。
但我還是覺得極度欣慰跟興奮，能協助並使得 PO 願意且有能力這樣帶領 team 來開發產品，PO 也覺得這是應該、這是正確的事。
我喜歡 jira 的 editor 格式針對 html table 的部分，剛好跟 cucumber gerkhin 的 table 一樣，看起來就是賞心悅目。這也讓我們在做轉換時，可以再省一點 effort 。
by the way, 目前這個模樣，就是 focus 在 "specification by example", 這還不是BDD，也不算是敏捷驗收測試 或 ATDD。這一步相當重要，對 PO 跟 team 來說都相當相當重要。
對 PO 來說，要學著用 example 來表達 scenario 與需求，並提煉出關鍵商業邏輯的 scenarios （所謂的關鍵，就代表每一個 scenario 會跑的程式碼流程都是不一樣的）。而且還要開始學習怎麼描述 what, why, behavior, 而不是 detail 的 how 或 UI 的動線與 spec。
對 team 來說，要開始從 scenarios 上的 domain keywords 去找出關鍵的 domain model/entity ，對不熟悉的詞彙在 refinement 要釐清意義與目的。並檢查 scenario 是否有頭有尾，而不是憑空出現。
對整個 scrum team 來說，則是一個重大的里程碑。各個角色之間，不再各說各話，PO, QE, developer 都在正確的時間點（還沒開始做、還不知道誰做時），釐清需求，並建立共同的目標（驗收標準）。每個人都可以對 acceptance criteria 提出疑問、補充、修正，一旦擁有共識拍版定案，就代表最終產品只要滿足上面的 acceptance criteria 就代表滿足 story 的需求了。
當然，還有個重要的前提時，acceptance criteria 是可以隨時調整跟補充的。大家可能覺得，靠，那不就是隨時在需求異動？是的，擁抱變化，會有需求異動或調整，一定就是希望更能滿足使用者的需求。
但，如果程式滿足了所有的 acceptance criteria 並上線後，仍然有 defect 怎麼辦？
有 defect 就改啊，不然要怎麼辦？只是整個 scrum team 都很清楚的瞭解，這是漏了某個 acceptance criteria, 而不是 bug 。只要把 acceptance criteria 再補上去，並修改程式使其滿足所有的 acceptance criteria 即可。
看到差異了嗎？團隊不會再出現：「這是 common sense 啊！」「參考某某功能修改就好」「你規格沒寫清楚！」「你到底測過哪些東西？」
目標一致，不管需求在什麼時候、不管怎麼變，整個 team 就可以迅速地做出反應，這就是敏捷。
Search